There isn't a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it's impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

Software projects are a popular way of funding and organizing software development. They organize work into temporary, build-only teams and are funded with specific benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness.

In their ideal state, product-mode organizations are formed of loosely coupled, autonomous teams that respond rapidly to articulated and unarticulated user needs. On occasion however, opportunities arise that require a response involving coordination across multiple teams. If not managed effectively the outcome will result in missed revenue, unsatisfied customers and wasted team capacity. We refer to the organizational initiatives that respond to these opportunities as programs. In this article, we’ll share our experience managing programs in product-mode organizations through an example of a program gone bad.

Platform teams have a unique reliance on other teams to ensure adoption of their platform - getting code changes into other teams' codebase is critical to their success. There are a variety of patterns for that cross-team collaboration, and selecting the right ones depends on both the phase of platform adoption and the ability of both teams and codebases to accept external influence.

Conway's Law (formulated in 1968 by Melvin Conway) says that a system's design is constrained by the communication patterns of its designers. Birgitta, Mike, James, and I discuss the meaning of this principle and how we've seen it play out in our careers. We talk about its impact on the concept of Microservices, the importance of aligning with business capabilities, and the role of the inverse Conway maneuver.

Can a modular architecture improve software delivery? Yes! -but with some caveats. This article charts the journey of an enterprise who set out to shift their architecture to a more modular one in order to ease their growing pains. They found that modularity is a multifaceted solution that extends beyond architecture, into business lines of communication, team topologies and effective developer experience. By paying close attention to these factors, the enterprise was able to achieve significant uplifts in the delivery performance of their mobile applications.

Any significant software development effort requires several different activities to occur: analysis, user experience design, development, testing, etc. Activity-oriented teams organize around these activities, so that you have dedicated teams for user-experience design, development, testing etc. Activity-orientation promises many benefits, but software development is usually better done with OutcomeOriented teams.

Alignment maps are organizational information radiators that help visualize the alignment of ongoing work with business outcomes. The work may be regular functionality addition or technical work such as re-architecting or repaying technical debt or improving the build and deployment pipeline. Team members use alignment maps to understand what business outcomes their day-to-day work is meant to improve. Business and IT sponsors use them to understand how ongoing work relates to the business outcomes they care about.

One of the undecided problems of software development is deciding what the boundaries of a piece of software is. (Is a browser part of an operating system or not?) Many proponents of Service Oriented Architecture believe that applications are going away - thus future enterprise software development will be about assembling services together.

I don't think applications are going away for the same reasons why application boundaries are so hard to draw. Essentially applications are social constructions:

Bimodal IT is the flawed notion that software systems should be divided into these two distinct categories for management and control.

• Front Office systems (systems of engagement) should be optimized for rapid feature development. These systems of engagement need to react rapidly to changing customer needs and business opportunities. Defects should be tolerated as the necessary cost for this rapid development cycle.
• Back Office systems (systems of record) should be optimized for reliability. As systems of record, it's important that you don't get defects that damage the enterprise. Consequently you slow down the rate of change.

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

A business-capability centric team is one whose work is aligned long-term to a certain area of the business. The team lives as long as the said business-capability is relevant to the business. This is in contrast to project teams that only last as long as it takes to deliver project scope.

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

Pretty much all the practitioners I favor in Software Architecture are deeply suspicious of any kind of general law in the field. Good software architecture is very context-specific, analyzing trade-offs that resolve differently across a wide range of environments. But if there is one thing they all agree on, it's the importance and power of Conway's Law. Important enough to affect every system I've come across, and powerful enough that you're doomed to defeat if you try to fight it.

When someone is looking at what makes up a top-class enterprise software developer, often the conversation may turn to knowledge of frameworks and languages, or perhaps the ability to understand complicated algorithms and data structures. For me, one of the most important traits in a programmer, or indeed in a development team, is something that I'll call Customer Affinity. This is the interest and closeness that the developers have in the business problem that the software is addressing, and in the people who live in that business world.

Agile software development has broken down some of the silos between requirements analysis, testing and development. Deployment, operations and maintenance are other activities which have suffered a similar separation from the rest of the software development process. The DevOps movement is aimed at removing these silos and encouraging collaboration between development and operations.

A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.

I use the term lay programmer to mean someone who is programming without thinking themselves as a programmer. Someone who spends a large part of her day working on spreadsheets is doing programming, often very intense programming. Usually however she won't call herself a programmer, nor think of spending much time learning how to program better.

People who sponsor development of software usually aren’t very interested in development metrics such as velocity or frequency of deployment to production. They care more about business benefits that the software will deliver such as lower manual effort, better sales conversion, greater customer satisfaction, i.e business outcomes. Outcome-oriented teams are those that are mandated and equipped to deliver business outcomes, such teams have people with the capability to carry out all necessary activities to realize the outcome.. By contrast, ActivityOriented teams are neither equipped nor mandated to do so. They can only perform one of several activities required to realize an outcome.

A bunch of common misconceptions about Pair Programming.

Improvements in communications technology have led an increasing number of teams that work in a Remote-First style, a trend that was boosted by the forced isolation of Covid-19 pandemic. But a team that operates remotely still benefits from face-to-face gatherings, and should do them every few months.

Imagine a hiring situation. There's two candidates both with a few years of experience. In the blue corner we have someone with good broad design skills in the style of design that you favor (in my case that would be things like DRY, judicious use of patterns, TDD, communicative code etc, but the actual list isn't important - just that it's what you favor). However she knows nothing of the particular platform technology that you're using. In the red corner we have someone who has little knowledge (or interest) in those issues, but knows your platform really well - edge cases in the language, what libraries are available, fingers move naturally over the tools. Assume all else about them is equal (which it never is except for thought experiments like this) and that your team doesn't have any gaping holes that this candidate might fill. Which one would you prefer?

One of the good things about software is that people seem to want it, and want it quickly. It's usual for organizations to ask teams to speed up production of software and from time to time the organization seeks to help in the way that really shows its commitment - by spending money to add more people to the team.

One of the most common ways to modularize an information-rich program is to separate it into three broad layers: presentation (UI), domain logic (aka business logic), and data access. So you often see web applications divided into a web layer that knows about handling HTTP requests and rendering HTML, a business logic layer that contains validations and calculations, and a data access layer that sorts out how to manage persistent data in a database or remote services.

I've spent a lot of time of the last year wandering around Thoughtworks, talking to lots of people on lots of projects. One message that's come home really firmly to me is the value of rotation.

This last week I had the pleasure of wandering around Florida speaking with Dan Sandlin and David LeBlanc at a series of Microsoft architecture councils. For those who don't know David LeBlanc wrote the very popular book Writing Secure Code with Michael Howard. At each of the session I would do a talk / q&a on P of EAA (which got a JavaWorld award this week) and David would follow on security.

Let's imagine a pretty world of SOA-happiness where the computing needs of an enterprise are split into many small applications that provide services to each other to allow effective collaboration. One fine morning a consumer service needs some information from a supplier service. The twist is that although the supplier service has the necessary data and processing logic to get this information, it doesn't yet expose that information through a service interface. The supplier has a potential service, but it isn't actually there yet.

In my recent CodeOwnership post, I described the way in which I think about code ownership issues. Many of my software development friends are extreme programmers, and tend to favor collective code ownership. However these kind of practices aren't absolute and should always be tempered by local considerations. One of my colleagues sent me a note with the following story which I thought was a good indication of when you have to vary your practices, even if you are a strong fan of XP. (As he's talking about his team, he prefers to be anonymous.)

The notion of changing software development from laboriously crafting code to building powerful systems by simple assembly of components has been a target since I entered our profession. It's target that is sometimes glimpsed, but never really attained - although many technologies have dangled the carrot of industrial reuse.

Any large software effort, such as the software estate for a large company, requires a lot of people - and whenever you have a lot of people you have to figure out how to divide them into effective teams. Forming Business Capability Centric teams helps software efforts to be responsive to customers’ needs, but the range of skills required often overwhelms such teams. Team Topologies is a model for describing the organization of software development teams, developed by Matthew Skelton and Manuel Pais. It defines four forms of teams and three modes of team interactions. The model encourages healthy interactions that allow business-capability centric teams to flourish in their task of providing a steady flow of valuable software.

Mobile applications have been a hot item in software development over the past couple of years. Like many software delivery companies, Thoughtworks get a lot of requests from clients asking us to build a mobile application for them. However most of the time a company asks us (or anyone) to build a mobile application they are starting off on the wrong foot. I'd argue that for most situations, even though you want users to interact with a mobile device, you should never think of building a mobile application. Instead you need to think about building a single application that presents across multiple devices: mobile, desktop, tablet - or whatever device your users might use.

A two-pizza team is a small team that fully supports software for a particular business capability. The term became popular as it used to describe how Amazon organized their software staff.

One of the steady themes I've seen throughout my career is that of the nature and importance of software development. A few years ago a prospect told one of our salespeople that “software is like sewage pipes, I want it to work reliably and I don't want to know about the details”. This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?